t
Object-oriented Programming (OOP)

*776**868*Just about everybody today would like you to believe their programming language is object-oriented. Even programming systems that merely support graphical-interface elements are leaping into the advertising arena wielding the sword of OOP. In reality, there is a great deal more to object-oriented programming than just a friendly interface and data types that sound like physical things rather than abstractions*223*.

In this section you briefly explore the basic concepts of object-oriented programming to enhance your understanding of programming activities in Part 2, “Tutorials.” This brief discussion is not meant to be a five page course on everything you always wanted to know about OOP. It is merely an introduction to the complex concepts at the heart of object-oriented programming. Should this introduction whet your appetite, see the “References” section at the end of this chapter for suggested reading. With this information as preparation, Part 2, “Tutorials” can further deepen your knowledge and appreciation of object-oriented programming.

 What Is Object-oriented Programming?

*763*Object-oriented programming is different from traditional programming in Basic, Pascal, C, or Lisp. OOP languages are not just new commands and syntaxes laid over the same old programming constructs. Object-oriented languages are based on a different perspective for thinking about problems to be solved through computing. 

*905*If you ask people what is different about object-oriented programming, most say, “Objects.” Certainly that is true at a superficial level. Objects are really just a tight grouping of a data structure and the program subroutines that know how to manipulate that structure. For a language to support objects it must adhere to the underlying principles of encapsulation,*317* inheritance,*475* and polymorphism.*830*10  You can demystify this OOP terminology by exploring a little everyday experience.

 How Do You Use Objects in Programming?

We view the world as a collection of objects. Everything around us is, in some sense, an object—from the gravel underfoot to the planets light-years away. We share our environment with an infinite set of discrete objects, each having individual characteristics, attributes*89*, and behaviors. Each object communicates*764* in its own way to other objects in the shared environment. Sometimes this communication is simply the act of being there; other times this communication is more active and interactive.

We first see the world in terms of objects, and then cluster together objects that are similar. We classify objects—for example, animal, mineral, vegetable, and so on—based on particular sets of distinguishing criteria, and we refine and reclassify, using greater detail and more criteria, such as physical attributes and exhibited behaviors:  Does it contain carbon? Does it produce seeds? Does it teach its young? Does it fly?

But ordering the world into classes of objects is not merely an academic exercise. We do this every day. For example, we classify people into occupational groups and specific job categories using descriptive lists of the job behaviors, skills, and acquired knowledge expected of members of each profession. By doing so we organize expectations about objects in our daily environment.

When you hire someone to carry out a particular task, you trust that he or she will exhibit the job behaviors, skills, and knowledge you expect. You ask the architect to design your dream home, confident that she will translate your ideas into blueprints for a builder. You hire a builder to put up the structure and find the electrician, bricklayer, plumber, and every other house-building person-object you need to raise the roof. You don’t ask how they will do what you request; you assume they know what needs to be done. You communicate with Ms. Architect and Mr. Plumber—person-object sending messages to other person-objects—expecting certain behaviors to occur.

 What Are Objects?

In object-oriented terms, occupational groups and job-descriptive categories are abstractions called*0159* classes. An abstract OOP class works something like a DNA template in genetics. It specifies a particular set of characteristics used for defining an “unborn” object of the class. It also identifies the particular skills and behaviors accessible to this unborn object—behaviors you can expect from members of the class.

*766*Ms. Jones, the architect, and Mr. Smith, the plumber, are both objects. They are individual instances  *497*of the classes Architect and Plumber respectively. As an instance of the class Architect, Jones has a specific educational background and a professional architect’s license. So do all other instances of the Architect class. And she uses Architect know-how, just as all other instances of Architect do. Smith has different descriptive attributes and different available know-how defined by the class Plumber.

In object-oriented programming, when you create a class*0152*, you specify a set of features and a library*510* of behaviors, called the attributes and methods  *712*of the class. Every instance created in that class is defined with the same attributes, although specific attribute values can vary from instance to instance. 

You open a Prograph class icon to see attributes and methods defined for instances of the class.

For example, each instance of class Plumber is specified by the attribute’s name, age, plumber’s rating, license number, and whether or not the plumber is bonded. Smith, one instance of class Plumber, is 35, is a journeyman, has license #J246, and is not bonded, while Brady—another instance—is 52, is a master plumber, has license # M52, and is bonded.

Every instance of a class can access the library of methods defined in that class. But in the same way that citizens use the resources of the town library, not every instance need use every method accessible to it. For example, in class Plumber, some instances might use only pipefitting methods, while others use only drain-cleaning methods.

And just as a DNA template is subject to evolutionary change, a class can be modified and updated. Attributes and methods of the class can be refined, redefined, or created, and all objects related to that class automatically “know” the changes. 

Most OOP languages freely let you add or delete methods to a class but restrict your ability to change the attribute structure. You are often required to “kill” all instances of a class before its attribute data structure can be modified. You then must recreate any instances lost to the update. Prograph is much more flexible. It allows you to alter the attribute structure of classes while instances are active. The changes made to the class definition are immediately transferred to the alive instances.

And so, an OOP object is basically its attributes and its know-how—related pieces of data and code. A class is the abstract template specifying attributes and know-how for instances of the class. An instance is a particular object of a particular class. 

A Prograph subclass*1021* inherits all attributes and the full library of methods specified in the parent class.

When a subclass of a parent class is created, the subclass inherits all attributes and the full library of methods of the parent class. This is called inheritance.*476* You create a subclass when you need an object that has slightly different attributes or methods than an existing class.

A subclass can vary from a parent class in several ways. It can add its own unique methods and attributes to those inherited from the parent class and it can overshadow*815* attributes and methods already defined in the parent class. 

When you define a method in a subclass using the same name as a method defined in the parent class, you overshadow a method. The subclass method preempts inheritance of the same-named method of the parent class.

Subclasses can be parents of subclasses. The inheritance*477* of attributes and methods flows downward in the family tree.  A class can inherit the combined attributes and methods of its parent, grandparent, and great-grandparent.

 How Do Objects Communicate?

*765*When you hire Jones or Smith to work on your house, you communicate a message. You expect that Jones, defined as an architect, uses Architect methods and that Smith uses the methods of class Plumber. An OOP object is merely a combination of attributes and know-how, but just as with real-world objects, you do not usually see all there is to see.

A Plumber object has attributes and knows plumbing methods. You know that a plumber knows how to install a faucet. You do not need to know all the details of what must be done to install a faucet:  all you need to know is the message, “Would you install a faucet in my kitchen?” Given this message, the plumber performs the various steps in doing the job. The “source code” of the plumber’s faucet-installing method is hidden—you only need to ask that it be done. This information hiding, also called encapsulation,*318* simply means that related data and program pieces—the object’s attributes and methods—are stored together in a kind of black box. You ask the object to act. You do not need to know how it is done.

When you send a message to an object, you communicate with the object as if it were a black box. You trust that the black box will carry out the task you expect of it, or if necessary send messages*770* to other objects that have the methods needed to get the job done. 

If water pipes break, you call a plumber (not an electrician) because the plumber is expected to have the tools and know-how to fix the broken pipes. You assume that the “black-box” plumber will fix the problem. If the plumber cannot do the job using his or her own plumbing methods, you expect he or she will call another person-object to help get the pipes fixed.

In OOP, objects communicate with other objects. Each object can send and receive certain messages. Each object can carry out particular methods, but methods do not directly communicate with methods. Rather, objects send messages to other objects, which then invoke appropriate methods. The situation is similar in Prograph, although a bit different conceptually.  In Prograph objects flow into operations to initiate some action, rather than stationary objects sending messages back and forth. The physical model varies, but the effect is the same. You can think of an object receiving a message in Prograph as being the same as an object flowing into a method-calling operation.

In general, an interesting phenomenon occurs when the same message is sent to different objects. Each object responds with a method appropriate to its class. This is called polymorphism  *831*in object-oriented terms. You can observe examples of such polymorphic behavior in objects around you. A generic message to move left can initiate tail swishing in fish, eight-legged scooting in spiders, and a polka hop or two in a couple on a dance floor. 
All object-oriented languages support polymorphism and inheritance as well as data abstraction and encapsulation to varying degrees. These concepts form the basis of object-oriented programming philosophy.

There are a number of excellent publications available for you to dig deeper into OOP concepts and any of the terms introduced in this section. A few are listed in the “References” section at the end of this chapter. Since object-oriented programming is rapidly moving to the forefront of today’s computing issues, you may want to spend some time investigating this area more fully.

Based on your Grand Tour experience and the reading you have already done here, you should recognize that Prograph is a highly visual as well as an object-oriented programming language. Prograph is also a diagram-based dataflow programming language, so we turn now for a brief look at dataflow programming.